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ABSTRACT 


The recent evolution of Internet, driven by the Web services 
technology, is extending the role of the Web from a support 
of information interaction to a middleware for B2B interac- 
tions. 

Indeed, the Web services technology allows enterprises to 
outsource parts of their business processes using Web ser- 
vices. And it also provides the opportunity to dynamically 
offer new value-added services through the composition of 
pre-existing Web services. 

In spite of the growing interest in Web services, current 
technologies are found lacking efficient transactional support 
for composite Web services (CSs). 

In this paper, we propose a transactional approach to en- 
sure the failure atomicity, of a CS, required by partners. We 
use the Accepted Termination States (ATS) property as a 
mean to express the required failure atomicity. 

Partners specify their CS, mainly its control flow, and the 
required ATS. Then, we use a set of transactional rules to 
assist designers to compose a valid CS with regards to the 
specified ATS. 


Categories and Subject Descriptors 


H.3.5 [Information Storage and Retrieval]: Online In- 
formation Services— Web-based services; H.2.4 [Database 
Management]: Systems—Transaction Processing; K.4.4 
[Computers and Society]: Electronic Commerce—Dis- 
tributed commercial transactions 


General Terms 
Design, Reliability 


Keywords 


Reliable Web services compositions, Failure atomicity, Trans- 
actional models 


1. INTRODUCTION 


Web services are emerging as a promising technology for 
automating B2B interactions. Nowadays, enterprises are 
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able to outsource their internal business processes as ser- 
vices and make them accessible via the Web. Then they 
can dynamically combine individual services to provide new 
value-added services. 

A main problem that remains is how to ensure a correct 
composition and a reliable execution of a composite service 
(CS) with regards to partners transactional requirements. 

Despite growing interest, Web services middleware is still 
rather primitive in terms of functionality, far from what cur- 
rent EAI middleware can provide for intra-enterprise appli- 
cations [2]. 

The current Web services technologies ensure communi- 
cation interoperability which is a part of the problem when 
considering the building of reliable Web services composi- 
tions [16]. Indeed, unlike activities in traditional workflows, 
services are defined independently of any computing context. 
Thereafter, the task of building composite Web services re- 
quires mechanisms to deal with the inherent autonomy, and 
heterogeneity of Web services. 

Although powerful, Advanced Transaction Models (ATMs) 
[6] are found lacking functionality and performance when 
used for applications that involve dynamic composition of 
heterogenous services in a peer-to-peer context. 

Their limitations come mainly from their inflexibility to 
incorporate different transactional semantics as well as dif- 
ferent interactions patterns into the same structured trans- 
action [8]. 

In this paper, we propose a transactional approach for 
reliable Web services compositions by ensuring the failure 
atomicity required by the designers. 

From a transactional point of view, we consider a CS as 
a structured transaction, Web services as sub transactions 
and interactions as inter sub transactions dependencies. We 
use the Accepted Termination States (ATS) property as a 
correctness criteria to relax atomicity. 

To the best of our knowledge, defining a transaction with a 
particular set of properties, in particulary ATS, and ensuring 
that every execution will preserve these properties remains 
a difficult and open problem [18]. 

The paper is organized as follows. Section 2 introduces 
a motivating example and gives the main points which has 
driven our approach. In section 3, we explain the notion of 
transactional web service and show how we express its trans- 
actional properties. Section 4 presents the notion of Trans- 
actional Composite (Web) Service (TCS) and explains our 
transactional point of view. Section 5 presents the notion 


of Accepted Termination States (ATS) as a mean to express 
the required failure atomicity. Section 6 illustrates how our 
approach proceeds (using a set of transactional rules) to 
assist designers to compose valid TCSs. In section 7, we 
discuss some related work. Section 8 concludes our paper. 


2. MOTIVATING EXAMPLE AND 
METHODOLOGY 


Let us first present a motivating example. We consider 
an application dedicated to the online purchase of personal 
computer. This application is carried out by a composite 
service as illustrated in figure 1. Services involved in this 
application are: the Customer Requirements Specifi- 
cation (CRS) service used to receive the customer order 
and to review the customer requirements, the Order Items 
(OI) service used to order the computer components if the 
online store does not have all of it, the Payment by Credit 
Card (PCC) service used to guarantee the payment by 
credit card, the Computer Assembly (CA) service used 
to ensure the computer assembly once the payment is done 
and the required components are available, and the Deliver 
Computer (DC) service used to deliver the computer to 
the customer (provided either by Fedex (DC rea) or TNT 
(DCrnr)). 


A N A N 
{ or) \ DC... j 
qd y ¢d sd 
a > A 4 A a D X 
{ CRS >N NiO} CA > 0O 
ww wil D x q yg ws R 
4 Ut D 4 
y s wan f DC 
{ PCC } \ TNT ] 
x y SS -d 


Figure 1: A composite service for online computer 
purchase. 


When a user designs a composite service, he expects the 
service execution to be reliable. That means he particularly 
pays attention to failure handling. In our example, the de- 
signer may want to be sure: that one of the two delivery 
services will succeed, that the service CA is sure to com- 
plete, and that it is possible for the service OI to undo its 
effects (for instance when the payment fails). These proper- 
ties define what we call the transactional behavior of the ser- 
vice. This behavior is specified using a set of transactional 
requirements. Since these requirements may vary from one 
context to another, the transactional behavior will vary too. 
For instance, a designer may accept the failure of the DC rea 
service in a context, while in another one he may not toler- 
ate such a failure at such an advanced stage. So the mean 
of a reliable execution is tightly related to transactional re- 
quirements and it may vary according to designers. 

In the same time, in order to ensure a reliable execution, 
we have to be sure that a specified transactional behavior 
is consistent with the set of selected services and the trans- 
actional requirements. Back to our example, we can easily 
notice that since the OI service is not sure to complete, the 
payment service PCC have to be compensatable (and it must 
be compensated when the OI service fails). 

The following points introduce our approach and its con- 
cepts for supporting this kind of scenarios. 

First, we believe that we must enhance Web services de- 
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scription for a better characterization of their transactional 
behavior. This can be done by enhancing WSDL interface 
with transactional properties. 

Second, we have to model services composition and chore- 
ography, in particular mechanisms for failure handling and 
recovery. 

Third, we have to provide designers with a mean to ex- 
press their transactional requirements, in particular their 
required failure atomicity level. Finally, we have to sup- 
port composite service validation with regards to designers’ 
requirements. 

In the rest of the paper we detail each of these issues 
and especially our set of transactional management rules 
for composite service validation. 


3. TRANSACTIONAL WEB SERVICE 
DESCRIPTION 


A Web service is a self-contained modular program that 
can be discovered and invoked across the Internet. Web 
services are typically built with XML, SOAP, WSDL and 
UDDI specifications [4] [17]. A transactional Web service is 
a Web service that emphasizes transactional properties for 
its characterization and correct usage. 

The main transactional properties of a Web service that 
we are considering are retriable, compensatable and pivot 
[14]. A service s is said to be retriable if it is sure to 
complete after several finite activations. s is said to be 
compensatable if it offers compensation policies to seman- 
tically undo its effects. Then, s is said to be pivot if once 
it successfully completes, its effects remains for ever and 
cannot be semantically undone. Naturally, a service can 
combine properties, and the set of all possible combinations 
is {r; cp; p; (r, cp); (r, p)}- 

In order to model the internal behavior of a service, we 
have adopted a states/transitions model. A service has a 
minimal set of states (initial, active, aborted, cancelled, failed 
and completed), and it also includes a set of transitions (ac- 
tivate(), abort(), cancel(), fail(), and complete()). The figure 
2.a shows the internal states/transitions diagram of a pivot 
service. 

When a service is instantiated, the state of the instance is 
initial. Then this instance can be either aborted or activated. 
Once it is active, the instance can normally continues its 
execution or it can be cancelled during its execution. In 
the first case, it can achieve its objective and successfully 
completes or it can fail. 

The requested transactional properties can be expressed 
by extending the service states and transitions. For instance, 
for a compensatable service, a new state compensated and a 
new transition compensate() are introduced (e.g., service in 
figure 2.b). Figure 2 illustrates the states/transitions dia- 
gram of a retriable service (figure 2.c) and states/transitions 
diagrams of services combining different transactional prop- 
erties (figures 2.d and 2.e). 

Within a transactional service, we also distinguish be- 
tween external and internal transitions. 

External transitions are fired by external entities. Typi- 
cally they allow a service to interact with the outside and to 
specify composite services choreographies (see next section). 
The external transitions we are considering are activate(), 
abort(), cancel(), and compensate(). 

Internal transitions are fired by the service itself (the ser- 
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Figure 2: Services states/transitions diagrams according to different transactional properties. 


vice agent). Internal transitions we are considering are com- 
plete(), fail(), and retry(). 


4. COMPOSITION OF TRANSACTIONAL 
WEB SERVICES 


A composite Web service is a conglomeration of existing 
Web services working in tandem to offer a new value-added 
service [13]. It coordinates a set of services as a cohesive 
unit of work to achieve common goals. 

A Transactional Composite (Web) Service (TCS) empha- 
sizes transactional properties for composition and synchro- 
nization of component Web services. It takes advantage of 
services transactional properties to specify mechanisms for 
failure handling and recovery. 


4.1 Dependencies between services 


A TCS defines services orchestration by specifying depen- 
dencies between services. They specify how services are cou- 
pled and how the behavior of certain service(s) influence the 
behavior of other service(s). 


DEFINITION 4.1 (DEPENDENCY FROM sı TO s2). A 
dependency from sı to s2 exists if a transition of sı can 
fire an external transition of s2. 


A dependency defines for each external transition of a 
service a precondition to be enforced before this transition 
can be fired. 

In our approach, we consider the following dependencies 
between services: 

Activation dependency from sı to s2: There is an 
activation dependency from sı to s2 if the completion of sı 
can fire the activation of so. 

We can tailor activation dependencies between services by 
specifying the activation condition, ActCond(s), of each ser- 
vice s. ActCond(s) defines the precondition to be enforced 
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before the service s can be activated (only after the comple- 
tion of other service(s)). There is an activation dependency 
from sı to s2 if f s1.completed E€ ActCond(sz2). Reciprocally 
for each service sı E€ ActCond(s2), there is an activation de- 
pendency from sı to s2 according to ActCond(s2). 

For example, the composite services defined in figure 3 
define an activation dependency from OI and PCC, to CA 
such that CA will be activated after the completion of OI 
and PCC. That means ActCond(C'A) = OI.completed N 
PCC.completed. 

Alternative dependency from sı to s2: There is an 
alternative dependency from sı to s2 if the failure of sı can 
fire the activation of s2. 

We can tailor alternative dependencies between services 
by specifying the alternative condition, AltCond(s), of each 
service s. AltCond(s) defines the precondition to be en- 
forced before the service s can be activated as an alterna- 
tive of other service(s). There is an alternative dependency 
from sı to s2 iff sı.failed E€ AltCond(s). Reciprocally 
for each service sı E€ AltCond(s2), there is an alternative 
dependency from sı to s2 according to AltCond(s2) 

For instance the composite service cs; in figure 3.b defines 
an alternative dependency from DC rea to DC rn such that 
DCrnv will be activated when DC reg fails. That means 
AltCond(DCrnr) = DC Fea. failed. 

Abortion dependency from sı to s2: There is an abor- 
tion dependency from sı to s2 if the failure, cancellation or 
the abortion of sı can fire the abortion of so. 

We can tailor abortion dependencies between services by 
specifying the abortion condition, AbtCond(s), of each ser- 
vice s. AbtCond(s) defines the precondition to be enforced 
before the service s can be aborted. There is an abortion 
dependency from sı to s2 iff s1.aborted E€ AbtCond(sz2)) V 
s1.failed E€ AbtCond(s2) V si.cancelled € AbtCond(s2). 
Reciprocally for each service sı € AbtCond(sz2), there is an 
abortion dependency from sı to s2 according to AbtCond(s2). 

Compensation dependency from sı to s2: There is 
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Figure 3: Two composite services defined according to the same skeleton. 


a compensation dependency from sı to s2 if the the failure 
or the compensation of sı can fire the compensation of s2. 

We can tailor compensation dependencies between ser- 
vices by specifying the compensation condition, CpsCond(s), 
of each service s. C'psCond(s) defines the precondition to 
be enforced before the service s can be compensated. There 
is a compensation dependency from sı to s2 iff s1.failed € 
CpsCond(s2) V s1.compensated E€ CpsCond(s2). Recipro- 
cally for each service sı E€ CpsCond(S2), there is a compen- 
sation dependency from sı to s2 according to CpsCond(s2). 

Composite services in figure 3 define a compensation de- 
pendency from PCC to OI such that OI will be comp- 
ensated when PCC fails. That means CpsCond(Ol) = 
PCC. failed. 

Cancellation dependency from sı to s2: There is a 
cancellation dependency from sı to s2 if the failure of sı can 
fire the cancellation of s2. 

We can tailor cancellation dependencies between services 
by specifying the cancellation condition, CnlCond(s), of 
each service s. CnlCond(s) defines the precondition to be 
enforced before the service s can be cancelled. There is 
a cancellation dependency from sı to s2 iff si.failed € 
CnlCond(s2). 

Reciprocally for each service sı E€ CnlCond(sz), there is 
a cancellation dependency from sı to s2 according to 
CnlCond(s2). 

Composite services in figure 3 define a cancellation depen- 
dency from PCC to OI such that OJ will be cancelled when 
PCC fails. That means CniCond(Ol) = PCC. failed. 

For clarity reasons, we do not deal with abortion depen- 
dencies. We call transactional dependencies the compensa- 
tion, cancellation and alternative dependencies. 


4.2 Relations between dependencies 
Dependencies specification must respect some semantic 

restrictions. Indeed, transactional dependencies depend on 

activation dependencies according to the following relations: 


Rı : An abortion dependency from sı to s2 can exist only 
if there is an activation dependency from sı to s2. 


R2: A compensation dependency from sı to s2 can exist 
only if there is an activation dependency from s2 to s1, 
or sı and s2 execute in parallel and are synchronized. 


R : A cancellation dependency from sı to s2 can exist only 
if sı and s2 execute in parallel and are synchronized. 


R4 : An alternative dependency from sı to s2 can exist only 
if sı and s2 are exclusive. 


Section 4.4 shows how these relations define potential de- 
pendencies induced by given activation dependencies. 


4.3 Control and transactional flow of a TCS 


Within a transactional composite service, we distinguish 
between the TCS control flow and the TCS transactional 
flow. 

Control flow: The control flow (or skeleton) of a TCS 
specifies the partial ordering of component services activa- 
tions. Activation dependencies between component services 
define the corresponding TCS control flow. 

We use (workflow-like) patterns to define a composite ser- 
vice skeleton. As defined in [7], a pattern “is the abstrac- 
tion from a concrete form which keeps recurring in specific 
non arbitrary contexts”. A workflow pattern can be seen as 
an abstract description of a recurrent class of interactions 
based on (primitive) activation dependency. For example, 
the AND-join pattern [21] (see figure 3.a) describes an ab- 
stract services choreography by specifying services interac- 
tions as following: a service is activated after the completion 
of several other services. 

Example: Figure 3.a illustrates a TCS skeleton defined 
using an AND-split, an AND-join and an XOR-split pat- 
terns. 


Transactional flow: The transactional flow of a TCS 
specifies mechanisms for failures handling and recovery. 


Transactional dependencies (like compensation, cancellation 
and alternative) define the TCS transactional flow. 


4.4 Pattern’s potential dependencies 


Several TCSs can be defined based on a skeleton. Each 
TCS adopts the activation dependencies defined by the skele- 
ton’s patterns and may extend them by specifying additional 
transactional dependencies. 

Example: Figure 3 shows two TCSs, cs; and cs2, de- 
fined using the same skeleton. Each of these TCSs adopts 
this skeleton (figure 3.a) and refines it with an additional 
transactional flow. 

Additional transactional dependencies are a subset of po- 
tential transactional dependencies defined by the skeleton’s 
patterns. Indeed, a pattern defines in addition to the default 
activation dependencies, a set of potential transactional de- 
pendencies. 

A potential dependency is a dependency that is not ini- 
tially defined by the pattern but that can be added by TCSs 
using this pattern. Potential dependencies are directly re- 
lated to the pattern’s activation dependencies according to 
the relations we have introduced in section 4.2. 

We have shown above that dependencies between services 
can be tailored by specifying preconditions on services’ ex- 
ternal transitions. And potential transactional dependencies 
are not an exception to this fact. So a TCS skeleton defines 
for each service the potential conditions corresponding to the 
potential dependencies. A pattern defines for each service s 
it is connected with: 


e ptCpsCond(s): its potential compensation condition, 
e ptAltCond(s): its potential alternative condition, 


e ptCnlCond(s): its potential cancellation condition. 


We can write each of these conditions in exclusive dis- 
junctive normal form. For instance, we can write the po- 
tential compensation condition of a service s as follows: 
ptC'psCond(s) = @, ptCpsCond;(s). Then ptCpsCond;(s) 
is one potential compensation condition of s. 

Example: The TCS skeleton illustrated in figure 3.a uses 
an AND-join pattern to define activation dependencies be- 
tween services OI, PCC and CA. According to the rela- 
tion Re given in section 4.2, a TCS based on this skele- 
ton can eventually specifies the following compensation de- 
pendencies: from OI to PCC, from PCC to OI, from 
CA to OI and from CA to PCC. Similarly, according 
to the relation R3, this pattern defines the following po- 
tential cancellation dependencies: from OJ to PCC, and 
from PCC to OI. That means, among other, that ptCp- 
sCond(PCC)=OL failed @Q CA.failed G CA.compensated 
and ptCnlCond(OI)=PCC. failed. 

In the same way, according to the relation R4, the XOR- 
split pattern connecting CA, DC rea and DCrnr defines the 
following potential alternative dependencies: from DC rnr 
to DC rea and from DC reg to DCrnv. 

That means that pt AltCond(DCrnr) =DC rea. failed and 
that DCrnr.failed = ptAltCond(DC Fea). 

Finally, note that both TCSs cs; and cs2 define their 
transactional flow as a subset of the potential transactional 


142 


flow presented above. Both define compensation and can- 
cellation dependencies from PCC to OI. csi defines an 
alternative dependency from DC rea to DCrnv. 


5. FAILURE ATOMICITY REQUIREMENTS 
OF A TCS 


Several executions can be instantiated according to the 
same TCS. The state of an instance of a TCS composed of 
n services is the tuple (21, £2, ..., £n), where x; is the state 
of service s; at a given time. The set of termination states 
of a TCS cs, STS(cs), is the set of all possible termination 
states of its instances. 

Back to our motivating example limited to the three ser- 
vices CRS, OI and PCC, we can have the following set of 
termination states: (CRS.completed, OI.completed, PCC. co- 
mpleted); (CRS.completed, OlI.failed, PCC.completed); 
(CRS.completed, OI.completed, PCC. failed); (CRS.compen- 
sated, OI. failed, PCC. initial); (CRS.compensated, OL. initial, 
PCC. failed); (CRS.compensated, OI. failed, PCC. failed). 

In order to express the designer’s requirements for failure 
atomicity, we use the notion of Accepted Termination States 
({18]). In other word, the concept of ATS represents our 
notion of correction. 


DEFINITION 5.1 (ACCEPTED TERMINATION STATES). 
An accepted termination state, ats, of a composite service cs 
is a state for which designers accept the termination of cs. 
We define ATS the set of all Accepted Termination States 
required by designers. 


An execution is correct iff it leads the CS into an ac- 
cepted termination state. A CS reaches an ats if (i) it 
completes successfully or (ii) it fails and undoes all undesir- 
able effects of partial execution in accordance with designer 
failure-atomicity requirements [18]. 

Back to our example, a designer may choose the following 
ATS: ATS(CS)={(CRS.completed, OI.completed, PCC.co- 
mpleted); (CRS.compensated, OI. failed, PCC.failed)} that 
means that an execution is correct when all of the services 
complete, or when CRS is compensated (given the failure of 
OI and PCC). Obviously, we note that a composite service 
transactional behavior may vary according to the required 
ATS. 


6. TRANSACTIONAL RULES 


To explain the rules and to illustrate how they are work- 
ing, we go back to our motivating example of personal com- 
puter online purchase. We suppose in addition that design- 
ers specify the ATS illustrated in the figure 5 to express 
their required failure atomicity. 

Intuitively, the execution of a composite service can gen- 
erate various termination states. A composite service is not 
valid if it exists some termination states that do not belong 
to the ATS specified by the designers. 


DEFINITION 6.1 (VALIDITY ACCORDING TO AN AT'S). 
A CS cs is said to be valid according to ATS iff its set of 
termination states is included in ATS, written STS(cs) C 
ATS. 


Example: The composite service cs; (illustrated in figure 
3.b) is valid because ST'S(cs;) € ATS. However regard- 
ing the composite service cs2 (illustrated in figure 3.c), we 


Initial TCS 


O 


-O 


Od ATS = {A.completed,...} 


definition 


OO 
PS o 


Pick up some 


services using pattern 
Transactional 
properties 
computing We use... 
= to compute... 
z to ensure 
Computer 
Valid TCS 
composition 
Select new services 
An engine 
dynamically pa 
ensures the 
compliance Specify new additional 
with the i 
dependencies 
generated 
transactional P 
properties e“ -O 
Pa 


V 


Compose them 


x 


`~ 


Extend pattern 
with additional 
dependencies 


Specify the 
required ATS 


Transactional validity rules 


Transactional properties 


The appropriate transactional behavior 
for valid TCSs 


Execution engine 


Execution of the TCS 
with the appropriate 
transactional behavior 


Figure 4: Objective and overview of our approach. 
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Figure 5: ATS used in our example 


note that ST S(cs2) contains the following termination state, 
(CRS.completed, OI. failed, PCC.completed, CA.aborted, 
DC Frea.aborted, DCrnr.aborted), which is not an accepted 
termination state. Thereafter cs2 is not valid. 


6.1 Objective and overview 


As illustrated in figure 4, our approach applies in a top- 
down manner. 

Definition of an initial TCS: First, designers dynam- 
ically choose some available services and combine them to 
offer a new value added service. They compose the new 
service using a set of interactions patterns (sequence, AND- 
split, AND-join,...). 

They can augment this skeleton by new dependencies se- 
lected from the potential dependencies. Then they express 
their required failure atomicity by specifying the required 
ATS. 

Compute validity transactional properties: We use 
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of PC online purchase. 


a set of rules, independent from skeletons and designers’ 
ATS, to compute from the TCS skeleton and the required 
ATS a set of transactional properties. 

These transactional properties tailor the appropriate trans- 
actional behavior for valid TCSs. A TCS must satisfy these 
transactional properties to be valid. 

Definition of a valid TCS: If the initial TCS is not 
valid, designers can (i) select new services (with eventu- 
ally new transactional properties) and (ii) augment the same 
skeleton with new dependencies. During this phase an en- 
gine assist designers to compose a valid TCS by respecting 
the generated transactional properties. 

Once a valid TCS is reached, it can be deployed and exe- 
cuted. 


6.2 Extracting services conditions 


Tailoring the appropriate transactional behavior for valid 
composite services is equivalent to identify the appropriate 


Input: 
ATS: designer' ATS 
ptCpsCond(s): the potential compensation condition of s induced 
by the TCS skeleton. 
Output: 
atsCpsCond(s): the ATS compensation condition of s 
Data: 
ats: an accepted termination state in ATS 
s: a service in the TCS 
ptCpsCond (s): the current potential compensation condition 
in ptCpsCond(s) 
satisfied: a boolean variable, sets to true if the current 
ptCpsCond (s) is satisfied in the current ats 


Algorithm: 

Begin 

atsCpsCond(s) «—— false 

ats «— next ats in ATS 

while ats + null do 

if the state of s in ats is compensated then 

satisfied «—— false 

ptCpsCond (s)«— next ptCpsCond (s) in ptCpsCond(s) 

while not satisfied and ptCpsCond, (s) # null do 

if ptCpsCond (s) is satisfied in ats then 
ats CpsCond(s) «—— atsCpsCond(s) ® ptCpsCond (s) 
satisfied <—— true 
ptCpsCond(s) «—— ptCpsCond(s) - ptCpsCond (s) 
ndif 

ptCpsCond(s) «—— next ptCpsCond(s) in ptCpsCond(s) 

endwhile 

endif 

ats «—— next ats in ATS 


endwhile 
End 


Figure 6: The algorithm for extracting ATS com- 
pensation conditions of a service s from the specified 
ATS and the TCS skeleton. 


dependencies between services. We can deduce from the 
specified AT S and the TCS skeleton the services’ conditions 
corresponding to these dependencies. 

For each service s we distinguish (i) atsC'psCond(s), the 
ATS compensation condition deduced from AT'S, (ii) the 
ATS cancellation condition, atsCnlCond(s), deduced from 
ATS, and (iii) atsAltCond(s), the AT'S alternative condi- 
tion deduced from ATS. Below, we explain how we can 
deduce these conditions. 

The algorithm given in figure 6 allows to extract the ATS 
compensation condition for a given service s from the com- 
posite service skeleton and the required ATS. The principle 
is: a potential compensation condition of s becomes an AT'S 
compensation condition if it is satisfied in an ats € ATS 
such that the state of s in ats is compensated. We pro- 
ceed similarly to deduce AT'S alternative and cancellation 
conditions of each service. 

For instance in our example, the potential compensation 
condition of PCC, OI.failed, becomes an ATS compen- 
sation condition because it is satisfied in ats4 (in which 
the state of PCC is compensated). And since ats4 is the 
only ats in which PCC is compensated then we can de- 
duce that atsCpsCond(PCC) = OI.failed. Similarly we 
can extract the ATS cancellation condition for OI. ats5 
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is the only ats in which OI is cancelled. Furthermore, the 
potential cancellation condition of OI, PC'C.failed is sat- 
isfied in ats5. Then we can deduce that atsC'nlCond(s) = 
PCC. failed. Finally, we can deduce in the same way, from 
ats6 and pt AltCond(DCrwnr), that ats AltCond(DCrnr) = 
DC rea. failed. 

It is important to note that the ATS specified by the de- 
signers must be consistent with the pattern semantics. An 
ATS is consistent if it satisfies the following two conditions. 

First, each of its ats must be well-formed. An ats € ATS 
is not well-formed if it exists a service s such that none of 
its potential (or activation) conditions (corresponding to its 
state in ats) is satisfied (in ats). We can easily modify the 
previous algorithm to detect if it exists a not well-formed 
ats € ATS. 

Second, the set of all ats must be consistent. Such incon- 
sistency can be detected after the generation of transactional 
properties ensuring CSs validity. 

For instance given the following termination state (limited 
to the three services OI, PCC and CA) ts = (OI. completed, 
PCC.compensated, CA.aborted), we note, among other, that 
none of the service PCC potential conditions (OT. failed, 
CA. failed and CA.compensated) is satisfied in ts. So we 
can deduce that ts is not well-formed. 

To illustrate an ATS inconsistency, let us consider the fol- 
lowing ATS={ats; = (OI.completed, PCC.completed, CA.co- 
mpleted); ats2 = (Ol.completed, PCC. failed, C'A.aborted); 
ats3 = (OI.compensated, PCC.failed, CA.aborted)}. Note 
that ats; and ats2 are contradictory because the service OI 
once it is completed (in ats2) and once it is compensated (in 
ats3) for the same condition (PCC. failed N CA.aborted). 
Thereafter the given ATS is not consistent although each of 
its ats is well-formed. 


6.3 Transactional validity rules 


An AT'S also defines the accepted termination states of 
each component service. We denote AT S(s) the set of ac- 
cepted termination states of a component service s. Regard- 
ing our illustrative example, we can deduce, for instance, 
that ATS(PCC) = {completed, failed, compensated} and 
ATS(CA) = {completed, aborted}. 

We can now introduce validity rules we are using to gener- 
ate transactional properties that ensure validity (we suppose 
that OF means that F is eventually true): 

Vs| s is a component service in TCS 


1. s.failed € ATS(s) => generate the following trans- 
actional property TP; : s must be retriable 


2. s.compensated ¢ AT S(s) => generate the following 
transactional property TP? : there is no need for s to 
be compensatable 


3. VatsCpsCond;(s) € atsCpsCond(s), generate the fol- 
lowing transactional property TPs”? : 
©(atsCpsCond;(s)) => 


(a) s must be compensatable and 
(b) atsCpsCond;(s) E€ CpsCond(s). 


4. VatsCnlCond;(s) E€ atsCnlCond(s), generate the fol- 
lowing transactional property TPS" : 
©(atsCniCond;(s)) => 
atsC'nlCond;(s) E€ CnlCond(s). 


5. VatsAltCond;(s) € atsAltCond(s), generate the fol- 
lowing transactional property T P32": : 


©(atsAltCond;(s)) => ats AltCond;(s) € AltCond(s). 


The first rule postulates that if the state failed does not 
belong to the AT'S of s, then it exists a transactional prop- 
erty saying that s must be retriable. 

The second rule postulates that if the state compensated 
does not belong to the AT'S of s, then it exists a trans- 
actional property saying that there is no need for s to be 
compensatable. 

The third rule postulates that for each ATS compensa- 
tion condition of s, atsC'psCond;(s), it exists a transac- 
tional property saying that: if this condition is eventually 
true then s must be compensatable and atsC'psCond(s) be- 
comes a compensation condition of s. That means Vs’ € 
atsCpsCond;(s) add a compensation dependency from s’ to 
s according to atsC'psCond;(s). 

The fourth rule postulates that for each ATS cancella- 
tion condition of s, atsCnlCond;(s), it exists a transactional 
property saying that: if this condition is eventually true then 
atsC'nlCond(s) becomes a cancellation condition of s. That 
means Vs’ € atsC'nlCond;(s) add a cancellation dependency 
from s’ to s according to atsCnlCond;(s). 

The fifth rule postulates that for each ATS alternative 
condition of s, ats AltCond;(s), it exists a transactional prop- 
erty saying that: if this condition is eventually true then 
atsAltCond(s) becomes an alternative condition of s. That 
means Vs’ € atsAltCond;(s) add an alternative dependency 
from s’ to s according to ats AltCond;(s). 

Example Back to our example, we can compute the fol- 
lowing transactional properties: TPy(ATS, CSskeleton) = 
{TPors; TPoa, TP parys TP% 4, TP pgs TPDcryr’ 
TPhop. a EP Eien TPH, TPO}, TP bryr) 

e By applying the first rule and since the state failed 
does not belong to ATS(CRS) we get the transac- 
tional property TPGrg : CRS must be retriable. Simi- 
larly, we can compute the following transactional prop- 
erties: TPG, : CA must be retriable and TP5 
DCrnr must be retriable. 


CTNT * 


e By applying the second rule and since the state com- 
pensated does not belong to ATS(CA) we get the 
transactional property TP?,, : there is no need for CA 
to be compensatable. Similarly we can compute the fol- 
lowing transactional properties: TP% pg, TPbcryr’ 


and TPC rea! there is no need for CRS, DCrnr, 
DC rea to be compensatable. 


e By applying the third rule and since atsCpsCond(PCC) 
= OI failed we get the transactional property TP $to : 
©(OI. failed) (means that OI is not retriable) ==> 


(a) PCC must be compensatable and 
(b) PCC must be compensated when OF fails. 


e By applying the third rule and since atsCpsCond(O1) 


= PCC failed we get the transactional property TPG? : 


©(PCC. failed) (means that PCC is not retriable) 
=> 


(a) OI must be compensatable and 
(b) OI must be compensated when PCC fails. 
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e By applying the fourth rule and since atsCnlCond(O1) 
= PCC. failed we get the transactional property TP a : 
©(PCC. failed) (means that PCC is not retriable) 
=> OI must be cancelled when PCC fails. 


e By applying the fifth rule and since DC rea.failed = 
atsAltCond(DCrnr ) we get the transactional prop- 
erty TPS Gs : O(DC Frea. failed) (means that DC rea 
is not retriable) => DCrnr must be activated when 
DCFED fails. 


The composite service csı verifies all the validity rules 
and thereafter it is valid. However the composite service 
cs2 verifies all the validity rules except the Redo rule. This 
rule postulates that if the compensation condition of PCC 
(which is the failure of OJ) is eventually true (which is the 
case in cs2) then PCC must be compensatable and must be 
compensated when OI fails (which is not the case in cs2). 
The composite service cs; respects this rule since OI is sure 
to complete and thereafter never fails. 


6.4 Validity rules proof 


We use the following lemma (the proof is not shown due 
to lack of space). 
Lemma A TCS termination state ts is not an accepted 
termination state iff 3 a service s such that 


e the termination state of s in ts ¢ AT S(s) or 


e none of its ATS potential conditions (corresponding to 
its state in ts) is satisfied (in ts). 


Proving that: (cs satisfies all validity rules <= cs is valid) 
is equivalent to proof that: (cs is not valid <> J a rule such 
thats cs does not satisfy this rule). 

1) =>: cs is not valid means that it has a not valid termina- 
tion state. That means (using the lemma above) either (a) 
it exists a service s which terminates in a not valid state or 
(b) it exists a service s which terminates in a valid state but 
without satisfying one of its ATS conditions corresponding 
to this termination state. (a) means that cs does not verify 
the validity rules 1 or 2. (b) means that cs does not verify 
one of the validity rules 3, 4 or 5. 

2) <=: (a) If cs does not verify one of the validity rules 
1 or 2 then it exists a service s which will terminate in a 
non valid termination state. (b) if cs does not verify one of 
the validity rules 3, 4 or 5 then it exists a service s which 
will terminate in a valid state without satisfying none of 
its corresponding ATS conditions. (a) and (b) means that 
(using the lemma above) cs is not valid. 


6.5 Implementation 


We are currently developing a prototype that supports 
this work. Our prototype is written in Java. 

The first part of the prototype is the transactional engine. 
It allows the user to select the services (with transactional 
properties), to define the TCS skeleton using patterns, and 
to specify the required ATS. The engine uses the transac- 
tional rules to compute the appropriate transactional prop- 
erties for valid TCSs. Then, it assists designers to compose 
a valid TCS by respecting these transactional properties. 

Window 1 of figure 7 shows how designers can choose ser- 
vices from the “Web services” scroll panel. It typically shows 
the transactional properties of the chosen service. 
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Figure 7: A screen shot illustrating the application of our transactional approach. 


Window 2 of figure 7 illustrates how designers can specify 
the TCS skeleton using patterns from the “operators” panel. 

Finally, window 3 of figure 7 illustrates how the transac- 
tional engine computes the appropriate transactional prop- 
erties from the required ATS. 

The second part of the prototype is a workflow engine 
that is able to execute the composite service. Our work- 
flow engine is Bonita, a workflow engine supported by the 
Object Web consortium ([20]). Bonita is a cooperative work- 
flow system supporting the specification, the execution, the 
monitoring, and the coordination of the processes. The main 
features of Bonita are: a third-generation workflow engine 
that can be parameterized by an activity model, a web 
interface to control workflow processes (accessing workflow 
methods as J2EE-based web services), an implementation 
using J2EE Enterprise Java Beans, the possibility to exe- 
cute code in the server side for different events (e.g., start 
and cancel activities) by means of hooks (hooks can be for 
instance Java programs, and may be assigned to process and 
node events), and the availability of a graphical user inter- 
face to design and control workflow processes, based on Java 
JFC/Swing. Of course, for our concern, the most interesting 
feature is related to the ability to define a specific model of 
services, including transactional states. 


7. RELATED WORK 


Advanced Transaction Models (ATMs) have been pro- 
posed to support new database applications by relaxing trans- 
action isolation and atomicity to better match the new re- 
quirements. As workflows in the past, services composition 
requirements either exceed or significantly differ from those 
of ATMs [6] in terms of modelling, coordination [22] and 
transactional requirements. Their limitations come mainly 
from their inflexibility to incorporate different transactional 
semantics as well as different behavioral patterns into the 
same structured transaction [8]. To overcome these limita- 
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tions, [18] proposed a transactional Workflows system sup- 
porting multitask, multisystem activities where: (a) differ- 
ent tasks may have different execution behaviors or prop- 
erties, (b) application or user defined coordination of the 
different tasks, and (c) application or user defined failure 
and execution atomicity are supported. In this approach, 
failure atomicity requirement is defined by specifying a set 
of ATS. Unfortunately, no transaction management support 
is provided to ensure this correctness criteria. Accepted ter- 
mination states as a mean to relax atomicity has been dis- 
cussed in many previous works |1, 5, 18]. In fact, ATS prop- 
erty has been always implicitly included in most of transac- 
tional models. For example, atomicity property implicitly 
defines ATS for traditional transactions; all (success state) 
and nothing (correct failure state). Also, when an advanced 
transaction model specifies global transaction structure, sub 
transactions properties, inter sub transaction dependencies, 
mechanisms of handing-over, success and failure criteria, 
and so on, it implicitly defines its ATS. In the same way, 
when [19, 23] define rules to form a well defined flexible 
transaction, they implicitly define the appropriate ATS for 
flexible transaction model. 

Emerging standards such as BTP [15], WS-transaction 
(WS-AtomicTransaction and WS-BusinessActivity [11, 12]), 
and WS-TXM (Acid, BP, LRA)[3] define models to support 
a two-phase coordination of web services. These proposals 
are based on a set of extended transactional models to spec- 
ify coordinations between services. Participants agree to a 
specific model before starting interactions. Then the cor- 
responding coordination layer technologies support the ap- 
propriate messages exchange according to the chosen trans- 
actional model. These propositions inherit the extended 
transactional models rigidity. Besides, there is a potentiel 
problem of transactional interoperability between services 
implemented with different approaches. Our approach can 
complement these efforts and overcome these two gaps. In- 
deed, our approach allows for reliable, more complex, and 


more flexible compositions. In addition, it can coordinate 
services implemented with different technologies since we use 
only services transactional features (and not interested in 
how they are implemented). So, we can use our approach to 
specify flexible and reliable composite services, while com- 
ponent services can be implemented by one of the above 
technologies. Once a valid TCS is reached, it can be consid- 
ered as a coordination protocol and can be plugged in one 
of the existing coordination technology to be executed. 


8. CONCLUSION 


In this paper, we have proposed a transactional approach 
for reliable Web services compositions by ensuring the failure 
atomicity required by the designers. 

Contrary to ATMs, our approach follows the opposite di- 
rection by starting from designers requirements to provide 
correctness rules. Like in [9, 18] (for transactions), designers 
define the global composite service structure, using patterns, 
and specifies required ATS as a correctness criteria. Then, 
we use a set of transactional rules to assist designers to com- 
pose a valid CS with regards to the specified ATS. 

The main contribution of our approach is that is able to in- 
corporate different interactions patterns into the same struc- 
tured transaction, and besides it can validate CSs according 
to designers transactional requirements. 


Acknowledgment: We would like to thank Laura Lozano 
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